Walking on water and developing software from a specification are easy if both are frozen.”

– Edward V. Berard

It is reality that specifications are almost never frozen and most projects build upon existing software. Even if developers really like green field projects, because they can play with new techniques and try out the latest concepts, those barely happen. To maintain high quality and velocity we must continuously refactor our software according to the changed requirements. Any pattern or architectural decision which fit the initial requirements might prove wrong in the long run.

This sounds like an awful working environment and is indeed a source of frustration for many developers – but there is something you can do about this.

We at Qafoo support very different customers over time to achieve this goal and learned many things by doing so. The first answer is choosing the right abstractions. We learned that this differs very much on the type of software you write.

• Product development
  We consider software developed by only one team or company a product. In this case you should not start with fancy abstractions from the very beginning. Only introduce new abstractions when your requirements make this necessary. This way you have to change less code when the requirements change.
• Library development
  Most libraries have a simple public API which must be stable. A library usually requires certain defined interfaces where other want to provide different implementations for. Think about log targets in Monolog.
• Project development
  If you develop a generic project like Shopware, Oxid or Spryker the agencies working with this software will want to adapt everything. You need sane abstractions from the very beginning – this requires upfront design.

As you can see even on the level of object oriented design your decisions matter for the long-term maintainability of your application.

The same is true for the architectural level. If you start with many Microservices from the very beginning before you even know how your software is used and where the Bounded Contexts are you will have a hard time refactoring the software later. Refactorings across multiple services are a lot harder then refactorings in just one application. If your requirements change over time this might even change the boundaries between your contexts. We learned that you probably want to start with a monolith first and maintain the right level of abstractions to be able to extract Microservices later.

Both is also true for very old software. PHP exists since quite a while and thus companies develop software since many years and businesses are built on this. If you want to stay in the market you must preserve agility to develop new features and fix bugs quickly. Knowing the most common issues with legacy software and ways to refactor them back into a maintainable state without breaking the functionality is a key ability. A beautiful thing about old software is that all the business logic is already there and you can discover the best patterns from the existing code and they will even be more stable then anything new you will write which still has to survive the market. Even if you do not work with old software knowing the common problems in legacy code will help you to avoid them.

While testing is important and many quality assurance tools can support you finding issues we consider refactoring one of the most crucial skills by now. You will always adapt your software continuously; be it since requirements change, to make software testable, to move to different architectural patterns or just to fix a bug. Learning the techniques behind this is essential and will even bring back the fun working with old software. It enables you to introduce new patterns, like Microservices, if you chose the correct level of abstraction. Be open for change.